Modeling Basic Aspects of Cyber-Physical Systems 



Walid Taha and Roland Philippsen 
Halmstad University, Sweden 
Rice University, Houston, TX 



Abstract — Designing novel cyber-physical systems entails 
significant, costly physical experimentation. Simulation tools 
can enable the virtualization of experiments. Unfortunately, 
current tools have shortcomings that limit their utility for 
virtual experimentation. Language research can be especially 
helpful in addressing many of these problems. As a first step 
in this direction, we consider the question of determining what 
language features are needed to model cyber-physical systems. 
Using a series of elementary examples of cyber-physical systems, 
we reflect on the extent to which a small, experimental domain- 
specific formalism called Acumen suffices for this purpose. 

I. Introduction 

Increasing the computational power of everyday products 
is revolutionizing the way we live. S eg ways can move us 
from one location to another without any need for large, 
cumbersome, or noisy vehicles. Cars can park themselves, 
and warn us when we are changing lanes unsafely. The future 
appears more fantastic than science fictions depicted it just 
a few years ago. At the same time, the increasingly tight 
coupling between computational and physical mechanisms, 
often described as cyber-physical systems (CPS), is creating 
a challenge for the traditional product development cycles. 
For example, car manufacturers are concerned about the 
amount of physical testing necessary to assure the safety of 
a car with a high degree of autonomy. 

Since the beginning of time, physical testing has been 
the basis for justified true belief in the qualities of a new 
product. A key ingredient of physical testing is having a 
collection of specific usage scenarios. But the presence of 
even simple computational components can make it make 
it difficult to identify enough usage scenarios to exercise 
more than a minute fraction of the possible behaviors of 
the system. These observations are spurring the developers 
of cyber-physical systems to rethink the traditional methods 
and processes for developing and testing new products. 

A. Virtual Experiments and Language Research 

One way to alleviate the testing problem is to use computer 
simulations [1] to perform virtual experiments [2]. Virtual 
testing can be used to quickly eliminate obviously bad de- 
signs. It can also help build confidence that a new design can 
pass test scenarios developed by an independent party [3]. 
Creating a framework for conducting virtual experiments 
requires a concerted, interdisciplinary community effort to 
address a wide range of challenges, including: 
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1) Educating designers in the cyber-physical aspects of 
the products they will develop, both in terms of: 

• How they these aspects are modeled, and 

• What types of system-level behaviors they gener- 
ate. 

2) Developing expressive, efficient, and robust modeling 
and simulation tools to support the innovation process. 
It is particularly important that the underlying models 
are: 

• Easy to understand and analyze at each stage of 
the design process, and 

• Easy to reason about across stages. 

3) Accumulating extensive libraries of component models 
that are both 

• Grounded in physical principles and analytic meth- 
ods, and 

• Validated experimentally. 

All three challenges would benefit from better language- 
based technologies for describing and simulating cyber- 
physical systems. Engineering methods centered around a 
notion of executable or effectively -computable models can 
have profound positive impact on the pace of advancement 
of knowledge and engineering practice in cyber-physical 
systems. 

1 ) The Educational Challenge: For decades, engineering 
and science education has focused on providing specialized 
training within well-defined disciplines. As a result, to design 
an advanced cyber-physical system such as a robot, we must 
engage several experts with advanced degrees from a number 
of different disciplines, such as mechanical engineering, 
electrical engineering, computer science, and biology. Not 
only does this recurring task make it difficult to assemble a 
team with necessary expertise for a project, the team may 
still lack a common language for discussing key issues that 
are fundamental to the design of robotic systems, but that 
are treated differently across disciplines. 

Addressing the educational challenge will require a con- 
certed effort to break down artificial boundaries between 
disciplines. A key step towards achieving this goal will be to 
find a lingua franca (or "common language") to communi- 
cate about fundamental issues that recur in the development 
of a variety of different cyber-physical systems. Part of such 
a language will be a jargon for communicating efficiently 
among experts; part will be an appropriate mathematical 
formalism. Language research can be particularly helpful 
in developing tools that are closely aligned with executable 
subsets (c.f. [4], [5]) of mathematical notations that are 
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already used by many engineers and scientists but are not 
available in mainstream programming languages and tools. 

2) The Modeling and Simulation Challenge: The model- 
ing and simulation challenge can also be approached from 
a linguistic point of view. Precise reasoning about models 
during each stage of the process can be improved by applying 
classical (programming) language design principles, includ- 
ing defining a formal semantics. Reasoning across stages can 
be facilitated by using two ideas from language design: 1) 
increasing the expressivity of a language to support multiple 
stages in the design process, and 2) automatically compiling 
models from one stage to the next to reduce manual work 
and opportunities for mistakes as models are translated from 
one stage of the design process to the next. 

3) The Modeling Library Challenge: It seems reasonable 
to expect that the dynamics surrounding the development 
and use of modeling libraries can be similar to those 
for software libraries. We can envision CPS design as a 
community process where there are library providers and 
library consumers, and where different libraries and test 
suites are used to benchmark and evaluate various offerings. 
In such a setting, the interfaces between components become 
important, motivating questions related to advanced linguis- 
tic techniques such as types, static checking, unit testing, 
contracts, assertions, assume-guarantee reasoning, and blame 
assignment, all of which can be expected to play a key role 
in addressing this challenge. 



B. A Small, Experimental Language for Hybrid Modeling 

To better understand the core linguistic issues that arise in 
addressing these challenges, we are developing a modeling 
language called Acumen [6], [7]. A key characteristic of 
modeling and simulation languages for cyber-physical sys- 
tems is supporting hybrid (continuous/discrete) mathematical 
models [1]. Modelica [8] and SimScape are widely used ex- 
amples of such languages. Hybrid modeling can be supported 
using a small number of constructs, namely: 

• Ground values (e.g., True, 5, 1.3, "Hello") 

• Vectors and matrices (e.g., [1,2], [[1,2], [3,4]]) 

• Object definition (class C (x,y,z) ... end) 

• Object instantiation and termination (create, 
terminate) 

• Variable declarations (including a special 
variable called _3D for generating visualizations) 
(private . . . end) 

• Variable derivatives (x' , x' ' , ...) 

• Continuous assignment ( [ = ] ) 

• Discrete assignment (=) 

• Conditional statements (if, and switch) 

• Expressions and operators on reals (+, -, ...) 

It appears that a language with just these features can be 
helpful in addressing the educational challenge. For example, 
we used such a language for a term-long project in an eight 
week course on cyber-physical systems [9], and seems to 
have been received positively. It appears that being able 
to concretely explain a wide range of concerns in a small 



language has two key benefits. The first relates to CPS edu- 
cation. Using a small language can help highlight the connec- 
tions between different concepts, and avoid the introduction 
of artificial distinctions between manifestations of the same 
concept in different contexts. The second relates to language 
and tools research. Showing how such a wide range of cyber- 
physical phenomena can be captured in a small language 
helps emphasize the expressivity of such a small language, 
and provide a basis for arguing against the introduction of 
additional language features until a compelling case for the 
addition of such language features has been made. 

These observations inspired us to step back from the 
details of that particular teaching experience to reflect on two 
questions relating to the challenges described above. First, 
what can we view as the basic cyber-physical aspects of a 
robot system? Second, how well can they be explained in 
terms of a small hybrid-systems modeling formalism? 

C Contributions 

This paper considers several aspects of cyber-physical 
systems that can be seen as common features of cyber- 
physical systems, and uses them to reflect on how they can 
be expressed and illustrated using the small hybrid systems 
modeling language introduced above. 

Visual and geometric presentation is a critical aspect of 
analytical modeling that can hide in plain sight (Section [II]). 
Technically, it is not part of analytical modeling, but it is 
indispensable for efficiently understanding both the specifi- 
cation and the results of a virtual experiment. From a peda- 
gogic point of view, the trigonometric reasoning involved in 
creating visualizations provides a natural path into geometry 
of motion (kinematics). Basic mechanics and dynamics come 
next (Section [In]), and a range of analytical principles used 
to model physical systems. They also motivate the use of 
differential equations, which in turn provide much of the 
background needed to motivate the discussion of control 
(Section [V]). To help experimentally evaluate the effect of 
control, it is useful to consider mechanisms for modeling 



disturbances (Section VI). By introducing these aspects, we 
are able to present the simplest possible example of how 
to model and test a cyber-physical system. This allows us 
to return back to the physical component and refined it. A 
natural way to do this in the robotics domain is to use ideas 
from rigid body dynamics (Section |VII| ). Similarly, we can 
refine the model of the control system by capturing the way 
in which implementation on a digital computer introduces 
both discretization and quantization effects (Section VIII| ). 

After the discussion of the individual aspects has been con- 
sidered, we summarize our observations about the language 
(Section |IX|) and conclude. 



II. Visual and Geometric Presentation 

Visual presentation plays an essential role in the design 
of cyber-physical systems. For many people, it is hard to 
imagine a robot (and possibly any other design, for that 
matter) without conjuring an image of a general physical 
form. If we want to replace physical prototyping with virtual 
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Fig. 1. The 3D output generated for an instance of the class sphere. 



prototyping, visualization becomes a necessity. From the 
educational point of view, this can be serendipitous, because 
it can provide an opportunity to introduce trigonometry, 
which itself is needed to model geometric features of objects 
as well as to work with both the kinematics and dynamics 
of physical objects. 

A. Drawing 3D Objects 

A small language for hybrid modeling and simulation 
can be easily extended with a lightweight mechanism for 
three dimensionals (3D) visualization [10]. In Acumen, the 
user can specify 3D visualizations through a special variable 
called _3D. This variable is only special in that it is read 
by the implementation and used to generate a dyanmic 3D 
scene. In principle, any graphical rendering technology can 
be used by an implementation to realize these visualizations. 
In practice, the current implementation used the Java3D 
library, which is built on tope of OpenGL. 

B. Class Definitions and Parameterization 

The following class definition specifies a particular way 
for drawing a sphere: 

class sphere (m,D) 
private 
P =[0,0,1]; 

_3D = [["Sphere", D+[0,0,1], 
. 03*sqrt (m) , 
[m/3, 2+sin (m) , 2-m/2] , 
[1,1,1] 1 1 ; 

end 

_3D [=] [["Sphere", D+p, 
. 03*sqrt (m) , 
[m/3, 2+sin (m) , 2-m/2] , 
[1,1,1] ] ] ; 

end 



The class parameter m represents a mass. This parameter 
is only used to pick a size and a color for the sphere. The 
parameter D is a display reference point. Passing different D 
values to individual objects facilitates creating visualizations 
where the individual objects appear in different places. The 
private section declares local variables as well as their initial 
value at the (simulated) time when the object is created. The 
variable p is used to represent the position of the sphere. 



The private section and the main body of the class definition 
contain similar expressions for _3D. Both expresions consist 
of a vector that has a format understood by the 3D visualiza- 
tion part of the Acumen implementation. The first definition 
is a discrete assignment that happens only at object creation 
time. The second expression is a continuous assignment that 
is computed all the time as long as the object exists in the 
simulation^ The format of the vector is as follows: The first 
field is a string indicating that the shape we want is a sphere. 
The second field is the coordinate for the center of the sphere. 
The next field is the radius. Here we compute chose to 
make the radius a simple function of the mass. This function 
is not intended to have any physical meaning. Rather, to 
produce reasonable effects for the examples presented in 
this paper. The next field contains a vector that represents 
the red/green/blue (RGB) colors for this sphere. To help us 
distinguish different objects, we have again used an ad hoc 
formula to generate a color based on the mass passed in. 
The last field can be used to express an orientation, and 
only matters when the sphere has a texture. Figure [T] depicts 
a visualization generated using this class. 

C Object Creation, Continuous Assignment, and Animation 

We can create sphere by writing "s = create sphere 
(5, [0,0,0])" in the initialization section and then "s.p [=] [0.1, 
0.2, 0.3]". To generate 3D animations, all we have to do is 
to let the value of "p" vary over time, as in the following 
code: 

class moving_sphere (m,D) 
private s = create sphere (m,D); 
t = 0; t' =0 

end 

t' [ = ] 5; 

s.p [=] [sin (t) *sqrt (1- (sin (t/10) ~2) ) , 
cos (t) *sqrt (1- (sin (t/10) ~2 ) ) , 
sin (t/10) ] ; 

end 

Here the variable t and its derivative t' are introduced here 
to model a local variable that progresses at exactly five times 
the rate of time. All that is needed to do that is to include 
the equation "t' [=] 5". The time-varying variable t is then 
used to generate some interesting values for the x, y, and 
z components of the the position field p that represents the 
center of the sphere object s. 

As noted earlier, we can have instances of the same 
object (such as the entire moving _sphere example) appear at 
different parts on the screen by varying the D parameter. By 
changing the value of the position parameter p, we can create 
an animation with two spheres moving in a synchronized 
fashion. 

It is useful to note that a 3D visualization facility can 
also be used to visualize not only 3D values but also scalar 
values. For example, it is useful to define objects that assist 
in visualizing specific scalar values during a simulation. The 

initialization is cumbersome in the current syntax for Acumen, as it 
requires using two very similar expressions. 
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following class defines a class to visualize a scalar value as 
a cylindar of length proportional to that value: 

class display_bar (v,c,D) 
private 

_3D = ["Cylinder", D+[0, 0.2,0], 
[0.02,v], c, 
[-3 . 14159265359/2, 0, 0] ] 

end 

_3D = ["Cylinder", D+ [ , . 2 , v/2 ] , 
[0.02,v] ,c, 

[-3.14159265359/2, 0, 0] ] ; 

end 

Following the string "Cylinder", the first value represents the 
center of the cylinder. We take this to be v/2 because this 
will allow us to keep one end of the cylinder fixed as the 
value of v changes. The next paramter is a tuple containing 
the radius and length of the cylinder. The next parameter is 
color. The last parameter specifies orientation angles for the 
cylinder. A screenshot of an instance of this class will be 
presented shortly. 

D. Vector and Trigonometric Calculation 

In many cases, it is necessary to perform a bit of geomet- 
rical calculation to create the desired shape. The need for 
such calculations can arise in situations that may be simpler 
than expected. An example of such a situation is drawing 
a cylinder between two points. Often, this cannot be done 
directly because many underlying visualization tools do not 
describe cylinders directly in this exact manner. Rather, it is 
common to use two angles that specify the orientation of the 
cylinder. Once we have figured out all necessary calculations, 
they can be encapsulated in one class as follows: 

class cylinder (D) 
private 
p =[0,0,0]; q= [ , , ] ; 
_3D = [["Cylinder", D, [0,0], 

[0,0,0], [0,0,0]]]; 
radius = 0.01; length = 0.01; alpha=0; 
theta= 3.14159265359/2; 
x=0;y=0; z=0 
end 

x [ = ] dot (p-q, [1,0,0]) ; 
y [ = ] dot (p-q, [0,1,0]) ; 
z [=] dot (p-q, [0,0,1]) ; 
length [=] norm (p-q); 
alpha [=] asin ( z/length) ; 
if (y>0) 

theta [ = ] asin (x/ ( length*cos (alpha) ) ) 
else 

theta [=] -asin (x/ ( length*cos (alpha) ) ) 
+ 3 . 14159265359 

end 

_3D [=] [ ["Cylinder", (p+q) /2+D, 
[radius, length] , 
[1,1,1], [alpha, 0, -theta] ] ] ; 

end 



The operators dot and norm operators compute the dot 
product and the vector norm (or length). Creating such an 
object is a good first exercise in coordinate transformation. 
Versatility with such transformations is an important skill for 
working with physical systems both in terms of Newtonian 
modeling as well as other, more advanced modeling tech- 
niques (c.f. [5]). Because they are executable models that 
produce visual results, developing small, purely graphical 
objects such as the ones above can be a gratifying way for 
students to learn about and practice the necessary geometric 
and necessary steps to understand how other aspects of robot 
mechanics and motion are modeled. 

III. Mechanics and Dynamics 

In contrast to the effort needed to describe geometric and 
visual objects, describing basic mechanical systems and their 
dynamics can be done more concisely. A point mass that can 
only move long dimension can be represented as follows: 

class mass_ld (m,p0,D) 
private 

p=p0; p'=0; p"=0; f=0; e_k=0; 
s=create sphere (m,D) 
end 

p" [ = ] f/m; 

e_k [=] .5 * m * (p' ) ~2; 
s.p [=] [0,0, p] 

end 

The object takes as parameters a mass m, an initial position 
pO, and a reference point for visualization^] Internally, the 
mass keeps track of a position p, its first and second deriva- 
tives p' and p", a force f, and the kinetic energy e_k. For 
visualization, a sphere object is created during initialization. 
The body of the class definition specifies that the acceleration 
of the object, p", is determined by Newton's law F = ma, 
where we are solving for acceleration (which is just p" 
here). The expression for energy uses the built-in dot-product 
operation on vectors. Finally, we set the position p of the 
visual object sphere to be the same as the position p of the 
current object. 

Supporting vector operations make it possible to define a 
similar object that has a three dimensional position almost 
just as simply: 

class mass (m,p0,D) 
private 

p= P 0; p' = [0,0,0]; p" = [0,0,0]; 
f= [0,0,0]; e_k=0; 
s = create sphere (m,D); 
end 

p" [ = ] f/m; 

e_k [=] 0.5 * m * (dot(p',p')) ~2; 
s.p [=] p; 

end 

2 For reasons of space, this paper uses short (often single-character) 
variable names. While this is closer to mainstream mathematical notation, 
in larger models it may be better style to use longer names for variables. 
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Note that it is convenient in this domain to have derivatives 
over vectors. We can induce continuous behaviors in such 
an object by mean of an external continuous assignment. For 
example, the effect of a gravitational force on a mass object 
m by a continuous assignment "m.f [=] m.m* [0,0,-9.81]". 
An idealized, 3D spring can be modeled as follows: 

class spring (k,10,D) 
private pl=[0,0,0]; p2=[0,0,0]; 

fl=[0,0,0]; f2=[0,0,0]; 
dl = [0,0,0]; e_p=0; 

end 

dl [=] p2-pl * (l-10/norm(p2-pl) ) ; 
fl [=] k*dl; 
f2 [=] -k*dl; 

e_p [=] 0.5 * k * dot(dl,dl); 
end 

This class associates a different force with each end of the 
spring, and that computes only a potential energy e_p rather 
than a kinetic energy. No visualization is included in this 
object, but that can be easily done using techniques presented 
above. 



A. Impacts and Discrete Assignment 

An important physical effect in dynamics is impact. Often, 
it is convenient to model impacts as a sudden effect. Discrete 
assignments can be used for this purpose. The following 
model provides an example of the use of discrete assignment 
to model the impact of a falling ball with a floor: 
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class bouncing_ball (D) 
private 



m 
bk 

bp 

bt 

end 
m.f 
if i 
m . p 



3, D) 



create mass_ld (10, 
create display_bar 

(0,[3,0.2,0.2],D+[ 0.1,0.2,0]); 
create display_bar 

(0, [0. 2, 3,0.2], D+[ -0.1, 0.2,0]) ; 
create display_bar 

(0,[0.2,0.2,3],D+[ 0,0.2,0]); 



[=] m.m * -9.81; 
m.p < & & m.p' 
-0.9 * m.p' 



< 0) 



end; 

bk.v [ = ] m.e. 
bp.v [=] 



bt.v [=] 

end 



k / (m.m * 
(m.m * 9.81 * 
/ (m.m * 9.81); 
bk.v + bp.v; 



9.81) 
m.p) 



The model uses the mass class along with a continuous 
gravity model and a ground-impact model where the ball 
looses 10% of its velocity. The class display _bar is used to 
display colored bars to present some additional information 
in the 3D output. The mass model used here has only one 
degree of freedom along the Z axis. We use three display 
bars to visually represent the kinetic and potential energy, 
as well as their sum. The discrete assignment occurs inside 



bit = create display cat c ■ ci, o.i. o\. 

[3, 0.2, 0.2]); 
bp = create display_bar (0, D + [-0.1, 0.2, 0] 
[0.2, 3, 0.2]); 
■ display bar (0, D + [0, 0.2, 0], 
[0.2, 0.2, 3]); 



bk.v [■] (0.5 * m.m * m.p' "2) / (m.m * 9.81) 
bp-v [■] (m.m * 9. SI * m.p) / (m.m * 9. SI) 
bt.v [■] bk.v + bp.v; 




Fig. 2. The Acumen IDE with the bouncing ball model and simulation 
results. The green bar indicates the potential energy, the red one is the 
kinetic energy, and the blue bar is their sum. The total energy decreases 
with each ground impact, and during the free flight phase the two energies 
behave as expected. 



the if statement that detects impact with the ground plane. 
Figure [2] shows a sequence of screenshots, one including the 
Integrated Development Environment (IDE), which results 
from running this example. It can be seen that, as expected, 
the total energy decreases at each impact, while the kinetic 
and potential energies reach their respective maxima and 
minima at the height of the bounce and the impact at ground 
level. 

Now we turn to creating systems made from components 
such as the mass and spring components that we have just 
introduced. 

IV. Capturing Conceptual Structure: Object 
Boundaries and Composition 

A benefit of using classes in defining a model is that 
it helps us think clearly about the conceptual boundary 
between the different components that we are modeling. 
Connecting components is a matter of relating fields in 
different components though continuous assignments. For 
example, the following class models a system consisting of 
three masses connected by two springs: 



class example_3 
private 



(D) 



create mass (15, [0,0, 1],D); 
create mass (5, [0,0,-l],D); 
create mass (1, [ , , -1 . 5 ] , D ) ; 
create spring (5,1.75,D); 
create spring (5,0.5,D); 
create display_bar (-1.5, 0,D) 



ml 
m2 
m3 
si 
s2 
b 
end 

sl.pl [=] ml.p; sl.p2 [=] m2.p; 
s2.pl [=] m2.p; s2.p2 [=] m3.p; 
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ml.f [=] sl.fl; 

m2.f [=] sl.f2 + s2.fl; 

m3.f [=] s2.f2; 

b. v [=] (ml.e_k + m2 . e_k + m3 . e_k 

+ si. e_p + s 2 . e_p ) * 1 2 ; 

end 

The class uses an instance of the class display _bar to draw 
a cylinder to display the kinetric energy in the system. Even 
though this is quite a simple dynamical system, it can be 
used to consider and illustrate several simple but nevertheless 
fundamental aspects of control. 

V. Control 

The goal of control is to bring a certain quantity close to 
a desired goal. In the context of the model presented above, 
and given a controller object c, the introduction of such a 
controller can be modeled as follows: 

// Goal is spring length at rest 
eg [ = ] sl.l+s2.1; 

// Value is actual spring length 

c. v [=] ml.p-m3.p; 

// Add c.f 
ml.f [=] sl.fl + c.f; 
m2.f [=] sl.f2 + s2.fl; 

// Subtract c.f 
m3.f [=] s2.f2 - c.f; 

In this model the goal value for the controller is to have the 
length of the system be the same as the natural lengths of 
the two springs. The quantity that we wish to control is the 
position of the first mass minus the position of the third one. 
The way we will achieve that is to take a force value f that is 
generated by the controller and apply it to both sides of the 
system that we have constructed, but in opposing directions. 

Now the question that remains is how the controller c 
should compute its output force f given the goal g and mea- 
sured value v. This is a prototypical question in the design of 
control systems, and that can be approached in a variety of 
different ways. Three of the most basic types of controllers 
are 1) proportional feedback, 2) proportional/differential 
feedback, and 3) proportion/integral/differential feedback. 
The first type can work for systems without inertia, or that 
have intrinsic ways of dissipating inertial energy. It can be 
modeled as follows: 

class f orce_controller_p (k_p) 
private g=[ 0,0,0]; v= [ 0,0,0]; 
f=[0,0,0] 

end 

f [=] k_p * (g-v) 
end 

The force f computed is directly proportional (hence the 
name) to the difference between the goal g and current value 
v of the quantity that we want to control. The higher the 



constant k_p, the higher the force that will be applied for 
the same amount of difference (or "error") between the goal 
value and the current value. 

If the system has inertia or does not dissipate the extra 
energy introduced by the control force, it might oscillate 
indefinitely as a result of the proportional control. To deal 
with this problem, a slightly more sophisticated controller 
that can also add a force opposing the direction of the motion 
(or rate of change) of the value being measured. Such a 
proportional/differential (PD) controller can be defined as 
follows: 

class f orce_cont roller_pd (k_p,k_d) 
private 

g=[0,0,0]; v=[0,0,0]; s=[0,0,0]; 
f=[0,0,0] 
end 

f [=] k_p * (g-v) - k_d*s 
end 

Note that this controller has an extra field s that should be 
provided from outside the object to serve as the speed reading 
that should affect the final force f. 

An interesting feature of these two controllers is that 
they do not keep track of history. We may wish to build 
a controller that exerts a higher force only after a weaker 
force has been tested for some time. This can be helpful, 
for example, if there are external constant forces (such 
as gravity) acting on our system, and we do not know 
their precise quantity ahead of time. This type of behavior 
can be achieved by a proportional/integral/differential (PID) 
controller such as the following: 

class f orce_controller_pid ( k_p , k_i , k_d ) 
private 

g=[0,0,0]; v=[0,0,0]; s=[0,0,0]; 
f=[0,0,0]; i=[0,0,0]; i' = [0,0,0] 
end 

f [=] k_p* (g-v) + k_i*i - k_d*s; 

i' [ = ] (g-v) 

end 

The variable i is being used to integrate the difference 
between the goal g and the value v over time, so, no extra 
inputs are needed. 

Using the formalism presented so far, it is easy to simulate 
and visualize the several instances of the 3 -mass/2- spring 
example showing both the behavior of the mass and the 
energy of the system with different controllers. The ex- 
periment shows that a P controller will not dissipate any 
energy and therefore will not stabilize the system, and that 
in fact at times it will add energy to the system and at 
others absorb energy from it. In fact, this example motivates 
formally analyzing this system to show that this controller 
will function essential as simply another spring between 
the two extreme masses. The PD controller will suffice in 
stabilizing the system quickly, and this will be clear from 
the height of the bar representing the energy in the system. 
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VI. Disturbances 

To enhance the value of an experiment, whether it is a 
physical or a virtual experiment, it can be useful to introduce 
various sources of disturbance into the system. At least for 
preliminary experimentation, it can be sufficient to model 
such disturbances as autonomous sources of various forces. A 
simple example that can be used with the examples presented 
in this paper is as follows: 

class f orce_disturbance (k) 
private t = 0; t'=0; t"=0; f=[0,0,0] end 
t' [ = ] 4; f [ = ] k*[sin(t), cos (t) , 

sin(2*t+cos (3*t) ) ] 

end 

This example generates a circular motion in two dimen- 
sions, and a mildly eratic oscillation in the third dimension. 
The k parameter is used to determine the amplitude of 
the behavior. One can imagine further parameterizing the 
object with a frequency or with time- varying mixing of the 
signals along the different axes. To determine what type of 
disturbance is most useful for a particular class of problems 
requires experimental analysis and validation of the models. 
For the purposes of this example, the above model sufficies 
to give us some confidence that our controllers did not just 
work for the particular parameters that we used to test the 
various systems on. 

VII. Rigid Body Dynamics 

With basic particle dynamics and control concepts under 
our belt, we are ready to start looking at the rigid body dy- 
namics. A key feature of this level of analysis of mechanical 
systems is that we start to take into account both translational 
and rotational effects. It is also a useful level to illustrate 
some of the benefits of using vector algebra to model and 
reason about the dynamics of systems. For example, vector 
algebra can often allow us to think about problems in 2D 
and then have the results generalize naturally to 3D. For 
example, consider a rod which holds apart two masses (of 
m/2 each) at a given distance (visualized in Figure [5]). Now 
imagine that there are force vectors p and q acting on each 
end. What is the resulting acceleration on the system? The 
following class models the dynamics of such a rod: 

class rod (m, pO , qO , D) 
private 
length = norm (pO-qO ) ; 

p = pO; sp=[0,0,0]; q = qO ; sq=[0,0,0]; 
axis = (pO-qO ) /norm (pO-qO ) ; 
axis' = [0,0,0] ; axis " = [ , , ] ; 
core = (p0+q0)/2; 

core' = [0,0,0]; core'' = [0,0,0]; 
fp = [0,0,0] ; fq = [0,0,0] ; 
fp_axis = [0,0,0]; fp_orth =[0,0,0]; 
fq_axis = [0,0,0]; fq_orth =[0,0,0]; 
c = create dumbbell (1,1,D); 
end 

fp_axis [=] dot ( fp, axis ) ★axis 
/ norm (axis ) ; 




Fig. 3. The 3D visualization generated by the rod class. 

fp_orth [=] fp - fp_axis; 
fq_axis [=] dot ( fq, axis ) ★axis 

/ norm (axis ) ; 
fq_orth [=] fq - fq_axis; 
core'' [ = ] (fp + fq) /m; 
axis" [ = ] 2* (fp_orth-fq_orth) 

/ (m* length) ; 
p [=] core 

+ (axis * ( length/2 ) /norm (axis )) ; 
q [=] core 

- (axis * ( length/2 ) /norm (axis )) ; 
sp [=] core' + axis' * (length/2); 
sq [=] core' - axis' * (length/2) ; 
c.p [=] p; c.q [=] q; 
end 

It is easy to combin this system with a controller that 
works to move the point p to a predetermined location. An 
interesting question is what happens to the point q during the 
process, and whether that can also be controlled as well. This 
problem provides a natural starting point to study challenging 
questions such as the control of an inverted pendulum in 3D. 

VIII. Discretization and Quantization 

The one aspect of controllers that we have not captured in 
the models presented above is that controllers are generally 
implemented by digital computers. The most obvious new 
issues that result from this implementation strategy are dis- 
cretization (in time) and quantization (in the representation of 
physical quantities). Both effects can be concisely expressed 
in Acumen. To model discretization, the key mechanism that 
is needed is to define a local clock and to only allow actions 
to be performed (or to be observed) at clock transitions. 
The following class models a PID controller (like the one 
presented above) with discretization and quantization effects. 

class f orce_cont roller_pid_d 
(k_p, k_i , k_d, period) 
private g=[ 0,0,0]; v= [0,0,0]; s= [0,0,0]; 
f=[ 0,0,0]; t=0; t'=0; 
i=[0,0,0]; i' = [0,0,0] 

end 

t' [=] 1; 

if (t>period) 
t = 0; 

f [=] k_p* (g-v) + k_i*i - k_d*s; 
end; 
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i' [=1 (g-v) 

end 

The variables t and its derivative t' are used in a manner 
similar to what was done at the start of this paper to generate 
an interesting signal for moving _sphere. Here we do two 
new things with the variable t. The first is that we have a 
conditional statement based on this variable that waits until 
(t>period). The parameter period models the time it takes the 
particular microprocessor that implements our controller to 
produce the new value of the result of the controller. Once the 
condition is true the first thing we do is to reset the counter. 
The second is that we reset its value to using the statement 
"t=0" as soon as that condition is true. In addition to this 
reset, the conditional also alios the equation for variable f in 
the original model to take effect only for that instant when t 
has surpassed the value of period. Because no other definition 
is given for this value until this event occurs again (at the 
start of the next period), the value f remains constant until 
that change occurs. 

With this model, it is easy to illustrate that as the sampling 
period goes up, the system that we are trying to control can 
become unstable. 

Discretization can be modeled by adding another integer 
(or fractional) value that is updated (by either a whole integer 
or a fraction, depending on the quanta) when an underlying 
continuous value goes outside the range represented by the 
current quanta. 

IX. Discussion 

Developing the examples used in this paper points out 
several possible improvements on the current formalism may 
be necessary. In this section, we briefly point out ones that 
appear to be particular compelling. 

First, when we compose several examples together, the 
simulation can slow down. The formalism is currently imple- 
mented as a purely functional interpreter in Scala. This serves 
well the goal of having a well-defined semantics. However, 
we expect that there will be significant opportunities for 
improvement in terms of performance. 

Second, we have also noticed that numerical stability 
can be a concern, even for the simple examples presented 
here. The current implementation uses a forward Euler 
integrator to simulate the continuous behavior. While this 
is generally considered to be a simplistic numerical method, 
it is surprising that it is problematic even for the simple 
examples used in this paper. To address this problem without 
becoming dependent on a particular numerical method, we 
are investigating the use of interval and enclosure-based 
methods to define a semantics for the formalism. 

Third, the examples also illustrate that the language can 
benefit from improved syntactic support for several different 
features such as: A) variable declaration and initialization 
often seems redundant and/or verbose, B) quantization for 
vector-valued variable is currently verbose, C) discretization 
could benefit from introducing syntactic sugar for clocks, D) 
embedded software could be easier to model if it can be 
written directly in a form similar to traditional code. 



X. Conclusions and Future Work 

In this paper we used a small domain- specific modeling 
formalism aimed at hybrid systems to express a range of 
basic aspects of robot cyber-physics. By doing so we are 
able to illustrate how such a formalism can be a useful basis 
for learning and communicating about such concepts. At the 
same time, we hope that these examples help communicate 
the richness and the power of this formalism despite its small 
size. 

In future work, we would like to conduct similar studies 
to determine whether the same small formalism used here 
would suffice for expressing other aspects of robotic cyber- 
physics, including: more sophisticated control laws, models 
for joint and link composition, collision detection, impact 
dynamics, a validated model of a multi-link robot, and a val- 
idated model of a team of cooperating robots. We anticipate 
that the improvements suggested in the discussion section 
will be important for expressing these aspects naturally and 
concisely. 
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